Previous Next Tracker index See it online !

(71/314) 1916995 - TextTools: Toggle line comment - make extra space optional

Hello,
I am using Jedit4.3pre13 with TextTools-plugin 1.14 and have the following (minor) problem:

In the Text-Tools options I only use the following option:
Insert line comment at start of line

In my Edit-mode I have specified the following lines:
<PROPS>
<PROPERTY NAME="lineComment" VALUE="* " />
</PROPS>
and in the Rules section I have:
<EOL_SPAN TYPE="COMMENT1" AT_LINE_START="TRUE">*</EOL_SPAN>

So whenever a "*" is at the start of the line this is highlighted as a comment. But only a "* " should be recognized by toggle line comment as a comment.

This is very handy since it allows me to have line comments that are toggled and line comment that are not toggled.
If, for example, one has the following code:
*permanent comment for the first block
code
*permanent comment for the second block
* alternative code that can be toggled

Now one can select the four lines and switch between the two line blocks of code by applying (once) toggle line comment. The result would be the following:
* *permanent comment for the first block
* code
* *permanent comment for the second block
alternative code that can be toggled

Here, I found it disturbing that an additional space has been included by the toggle line comment. Instead of the expected "* " a "* " has been included (with two white spaces).

Note also that the actual text of the last line would be changed when twice toggled.

Certainly there are use-cases, where adding an additional space can be useful (in these use-cases the space is a feature, not a bug). However I would be very please if the inclusion of an additional space could be made optional - so one could choose if the space is needed or not. In my use-case the extra space is clearly not needed and leads to disturbing amount of space which encumbers readability.

Thanks a lot for providing the TextTools plugin. I have added the Toggle Line comment to the context menu and use it all the time!

Submitted	goebbe - 2008-03-17 - 17:01:56z	Assigned	ian_lewis
Priority	5	Category	None
Status	Open	Group	None
Resolution	None	Visibility	No

Comments

2008-03-18 - 02:25:19z ian_lewis	Logged In: YES user_id=478898 Originator: NO It makes sense that it inserts it with two spaces since toggle line comment inserts the line comment value, which in your case includes an extra space, and an extra space character. I'm a bit wary of adding another option for such a one off use case (there are already 3 options pertaining to how toggle line comment behaves). I'd kind of prefer if it just acted in a "reasonable" way without having a bunch of options. Like maybe, if the line comment includes a space already, then don't add the extra space. I'll try a couple things and see what might work best. I'm not completely against adding a new option but in the interest of keeping it rather simple, I feel like I should avoid it if possible.
2008-03-18 - 10:11:46z goebbe	Logged In: YES user_id=1050273 Originator: YES Thank a lot for the answer. Of course I understand your concerns about additional options. Actually it took me already some time to find out that there are options at all - and I was glad that I could adapt the behavior of the line comments to some extend. As a starting point I would like to develop what I had expected before applying the command called "toggle_line_comment" for the first time: a) First, I would guess that it works on a line per line basis (that is what line-comments are for) b) Second, I would guess that it stick to the property of the edit-file e.g. if <PROPERTY NAME="lineComment" VALUE="" /> then I would expect the command to include simply a "" (without extra whitespace, since the line comment does simply not include a space). c) Third, I would expect that applying the command twice to a line (or a block of lines) that I would always get back to the original text. Of course that is just me - and it is just taking reading the name of the command and thinking about what a command named goggle line comment will probably do. The following use cases would be covered by this simplest form of goggle line comments: 1. Someone has (manually) included a line comment (for one line) and wants to toggle the comment of the line 2. Someone has has one line of code and wants to toggle the line comment. 3. Someone has a mixture of (alternative) code lines (without "permanent" comments) and wants to toggle the line comments (e.g. switch between alternative blocks (lines) of code) The case that is more problematic is when it comes to the concept of "permanent"-line-comments i.e. line comments that should survive a toggle-line action. (obviously this is a very useful feature). The problem here is how to recognize "permanent" line comments, since without explicitly specifying, one needs to make assumptions / need heuristics which are likely to lead to unexpected results (from the users point of view) in some use-cases. Perhaps the following could provide a solid approach: - Stick to the simple approach - Introduce explicitly the concept of permanent line comments that can be configured by the user in the plugin- options. (I would not activate permanent line comments by default ) - One could use a sensible default proposal. e.g. twice the line comment as a default proposal (in my example: "*" for permanent instead of "" for standard line comments. If (and only if :-) ) still needded for some use-cases: - Introduce a "new" command called "toggle line comment blockwise". I think this title would make it clear what can be expected form the command. Here one needs some assumptions/rules/heuristics to determine the current state of a block, especially when the block contains a mixture of commented and uncommented lines. The proposed solution would have the virtue of being at the same time simple, easy to understand, user-configurable , serve a wide range of use cases and programming styles at the same time, respect the line comment that is specified by the property-tags in the Mode-files and make "toggle line comments blockwise" an alternative that can be applied without changing the plugin-options. Example: If the following code is selected and we apply the toggle line comment (with permanent line comment option on) *permanent line comment code1 code1 permanent line comment code2 One should get: permanent line comment code1 code1 permanent line comment code2 Sorry this text is much longer than it should be. Since I have no Java-skills at all I have not idea if my proposal could be implemented with a reasonable amount of work and perhaps there is a major oversight somewhere? Anyway, thanks a lot for providing the TextTolls-plugin and keep up the great work.

2008-03-18 - 02:25:19z
ian_lewis

Logged In: YES
user_id=478898
Originator: NO

It makes sense that it inserts it with two spaces since toggle line comment inserts the line comment value, which in your case includes an extra space, and an extra space character. I'm a bit wary of adding another option for such a one off use case (there are already 3 options pertaining to how toggle line comment behaves). I'd kind of prefer if it just acted in a "reasonable" way without having a bunch of options. Like maybe, if the line comment includes a space already, then don't add the extra space.

I'll try a couple things and see what might work best. I'm not completely against adding a new option but in the interest of keeping it rather simple, I feel like I should avoid it if possible.

2008-03-18 - 10:11:46z
goebbe

Logged In: YES
user_id=1050273
Originator: YES

Thank a lot for the answer. Of course I understand your concerns about additional options.
Actually it took me already some time to find out that there are options at all - and I was
glad that I could adapt the behavior of the line comments to some extend.

As a starting point I would like to develop what I had expected before applying the command called
"toggle_line_comment" for the first time:
a) First, I would guess that it works on a line per line basis (that is what line-comments are for)
b) Second, I would guess that it stick to the property of the edit-file e.g. if
<PROPERTY NAME="lineComment" VALUE="*" /> then I would expect the command to include simply a "*" (without extra whitespace, since the line comment does simply not include a space).
c) Third, I would expect that applying the command twice to a line (or a block of lines) that I would always get back to the original text.

Of course that is just me - and it is just taking reading the name of the command and thinking about what a command named goggle line comment will probably do.

The following use cases would be covered by this simplest form of goggle line comments:
1. Someone has (manually) included a line comment (for one line) and wants to toggle the comment of the line
2. Someone has has one line of code and wants to toggle the line comment.
3. Someone has a mixture of (alternative) code lines (without "permanent" comments) and wants to toggle the line comments (e.g. switch between alternative blocks (lines) of code)

The case that is more problematic is when it comes to the concept of "permanent"-line-comments i.e. line comments that should survive a toggle-line action. (obviously this is a very useful feature).
The problem here is how to recognize "permanent" line comments, since without explicitly specifying, one needs to make assumptions / need heuristics which are likely to lead to unexpected results (from the users point of view) in some use-cases.

Perhaps the following could provide a solid approach:
- Stick to the simple approach
- Introduce explicitly the concept of permanent line comments that can be configured by the user in the plugin- options. (I would not activate permanent line comments by default )
- One could use a sensible default proposal. e.g. twice the line comment as a default proposal (in my example: "**" for permanent instead of "*" for standard line comments.

If (and only if :-) ) still needded for some use-cases:
- Introduce a "new" command called "toggle line comment blockwise". I think this title would make it clear what can be expected form the command. Here one needs some assumptions/rules/heuristics to determine the current state of a block, especially when the block contains a mixture of commented and uncommented lines.

The proposed solution would have the virtue of being at the same time simple, easy to understand, user-configurable , serve a wide range of use cases and programming styles at the same time, respect the line comment that is specified by the property-tags in the Mode-files and make "toggle line comments blockwise" an alternative that can be applied without changing the plugin-options.

Example:
If the following code is selected and we apply the toggle line comment (with permanent line comment option on)
**permanent line comment
*code1
*code1
**permanent line comment
code2

One should get:
**permanent line comment
code1
code1
**permanent line comment
*code2

Sorry this text is much longer than it should be. Since I have no Java-skills at all I have not idea if my proposal could be implemented with a reasonable amount of work and perhaps there is a major oversight somewhere?
Anyway, thanks a lot for providing the TextTolls-plugin and keep up the great work.

(71/314) 1916995 - TextTools: Toggle line comment - make extra space optional

Comments

Attachments